Because the srv() function for a given queue is addressed from the associated qinit structure, there is no requirement that the srv() function be a public name, and no requirement that it begin with the prefix string.
The prototype of a svr() function is as follows:
The srv() function for the write queue, which handles messages moving "downstream" from the user process toward the driver, is conventionally called the wsrv() function. The srv() function for the read queue, which handles messages moving "upstream" from the driver toward the user process, is conventionally called the rsrv() function.int name(queue_t *q);
An srv() function is called by the STREAMS monitor to deal with queued messages. It is called at a time chosen by the monitor, not necessarily related to any call to the put() function for the same queue. In a multiprocessor, only one instance of srv() is called per queue at any time. However, one or more instances of the put() function could execute concurrently with the srv() function--so any data that is used in common by put() and srv() must be protected with a lock (see "Waiting and Mutual Exclusion"). User-level code can also execute concurrently with a service function.
The service function is expected to dispose of all queued messages through one of the following actions:
A STREAMS module or driver that is not multiprocessor-aware (lacks D_MP in its pfxdevflags) uses one set of functions for flow control (see the canput(D3) and bcanputnext(D3) reference pages), while one that is multiprocessor-aware uses a different set (see canputnext(D3) and bcanputnext(D3) ).